home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000063_owner-urn-ietf _Wed Nov 6 10:41:35 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12531 for urn-ietf-out; Wed, 6 Nov 1996 10:41:35 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12526 for <urn-ietf@services.bunyip.com>; Wed, 6 Nov 1996 10:41:27 -0500
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA10395  (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:41:23 -0500
  5. Received: by privateer.windrose.omaha.ne.us; Wed Nov  6 09:38 CST 1996
  6. Message-Id: <3280B0E8.6AF9@ds.internic.net>
  7. Date: Wed, 06 Nov 1996 09:38:16 -0600
  8. From: Ryan Moats <jayhawk@ds.internic.net>
  9. Organization: InterNIC Directory and Database Services
  10. X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c)
  11. Mime-Version: 1.0
  12. To: Keith Moore <moore@cs.utk.edu>, URN Mailing List <urn-ietf@bunyip.com>
  13. Cc: Terry Allen <tallen@fsc.fujitsu.com>, Lewis Girod <girod@LCS.MIT.EDU>,
  14.         Martin J Duerst <mduerst@ifi.unizh.ch>
  15. Subject: [URN] Comments on "I18N does not belong in URNs"
  16. References: <199611052333.SAA17528@ig.cs.utk.edu>
  17. Content-Type: text/plain; charset=us-ascii
  18. Content-Transfer-Encoding: 7bit
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Ryan Moats <jayhawk@ds.internic.net>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. All-
  25.  
  26. I'm going to try to munge my replies together to lots of mail
  27. that I saw this AM....
  28.  
  29. Keith Moore wrote (>):
  30. > 
  31. > Support for UTF-8 in URNs is a gross layering violation.  It also
  32. > violates the requirements of RFC 1737 in several ways:
  33.  
  34. Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD
  35. REASON and consensus.  (This is a null statement, but I wanted to make
  36. it anyway).
  37.  
  38. [Stuff snipped because I smell a rathole]
  39.  
  40. > URNs need to have global scope and to be transcribable.  Few people on
  41. > this planet could accurately transcribe more than a small percentage
  42. > of UTF-8.  Even those that could transcribe it could probably not type
  43. > most UTF-8 characters on their keyboards.  It's also completely
  44. > unacceptable to expect people to have a graphical display and hunt
  45. > through character menus just to type in a URN.
  46.  
  47. This gets close to the encoding issue, so I postpone comments to below.
  48.  
  49. > UTF-8 cannot be transported unmodified in common Internet protocols.
  50. > Even if some of those protocols are being upgraded to support more
  51. > charsets, it will be many years before UTF-8 can be transported safely
  52. > by these tools.
  53.  
  54. Terry Allen commented (|):
  55.  
  56. |That's an argument specifically against using UTF-8 at all.  I'd
  57. |like to hear more on this point from the UTF-8 proponents. 
  58.  
  59. Martin Duerst replied (@):
  60.  
  61. @The internet as such (TCP/IP) transports any kind of octets whatsoever.
  62. @Some of the higher level protocols fail in this respect because
  63. @of the short-sightedness of their designers. The worst is E-Mail,
  64. @because it works not only on the internet, but also with other
  65. @networks. But this is known, and with MIME, it is no problem
  66. @anymore.
  67.  
  68. @Also, the URN syntax draft clearly specifies how URNs are
  69. @transported over 7-bit channels (using %HH). This works for
  70. @URLs, there is no reason it shouldn't work for URNs.
  71. @ 
  72. @So I really wonder where there should be a problem.
  73.  
  74. Well, this is not exactly the way I interpret the syntax draft.
  75. Section 3 of the draft states that encoding URNs for transport
  76. is the responsibility of the transport protocol.  The implied statement
  77. is that the transport protocol is responsible for undoing the
  78. encoding.  The encoding section is there in the case of encoding
  79. that the URN resolver has to undo itself.  What I wonder (and
  80. am looking for some consesus on) is: "Is this necessary?"
  81.  
  82. Also, the %HH escaping technique does have some problems with UTF-8
  83. as Martin has pointed out on another thread...
  84.  
  85. [more stuff snipped because I smell another rathole]
  86.  
  87. > But incorporating UTF-8 in an attempt to make URNs human-readable is
  88. > an absolute showstopper.
  89.  
  90. Well, I'll let the folks who asked for it defend why they wanted it,
  91. but I know I don't make any mention of human readability in the URN
  92. syntax draft.  In fact, I view human readability as a namespace
  93. feature/bug/design goal and independent of the decision to support
  94. UTF-8 in the syntax doc.
  95.  
  96. Ryan